home *** CD-ROM | disk | FTP | other *** search
/ Tech Arsenal 1 / Tech Arsenal (Arsenal Computer).ISO / tek-20 / nos_kit3.zip / MAILDOC3.DOC < prev    next >
Text File  |  1991-03-15  |  23KB  |  661 lines

  1.          NOS mail docs -- G4AMJ/NQ0I and SM0RGV (Rev. 3)
  2.  
  3. Introduction
  4.  
  5. Intended audience
  6.  
  7. These documents are intended for the NOS system operator desiring
  8. to enable the forwarding of mail to other systems. They are NOT
  9. intended as a user guide for the mail capabilities of NOS.
  10.  
  11. Background
  12.  
  13. This section of the NOS docs deals with the intricacies of mail
  14. forwarding. You should read and understand this documentation
  15. thoroughly before attempting to forward mail through your NOS box
  16. to the AX.25 BBS world, otherwise you might grossly misconfigure
  17. your system and be the unhappy recipient of flames from BBS
  18. sysops.
  19.  
  20. This section does NOT deal with the minutae of the mailbox and
  21. its various commands; it assumes that you understand concepts
  22. such as user areas (both public and private) and how to list and
  23. send mail. If you need help with these, please look elsewhere in
  24. the NOS docs.
  25.  
  26. Apart from the usual domain.txt and other files necessary for
  27. ordinary functionality of NOS, three files are important in the
  28. mail forwarding process. These are : /spool/forward.bbs, /alias
  29. and /spool/rewrite. The contents of these will now be addressed
  30. individually.
  31.  
  32. /spool/forward.bbs
  33.  
  34. This file describes the actions taken by NOS in forwarding to
  35. AX.25 BBSes. The file contains a series of forwarding records,
  36. each record being separated by a line containing two or more
  37. hyphens. The template for a forwarding record is:
  38.  
  39. BBS callsign
  40. Connection route
  41. Connection commands                <zero or more lines>
  42. List of areas to be forwarded      <one per line>
  43. ------------                       <end of record>
  44.  
  45. BBS callsign
  46.  
  47. This is simply the ordinary call of the remote BBS. A typical
  48. (but not random!) entry might be simply the line:
  49.  
  50. sm0rgv
  51.  
  52. The callsign may be followed, on the same line, by a comma
  53. separated list of valid intervals when forwarding is to take
  54. place. Each valid interval is a four digit number: the first two
  55. digits are the beginning hour of the valid interval, the last two
  56. digits are the final hour of the valid interval. For example, if
  57. the first line of a forwarding record looks like:
  58.  
  59. sm0rgv 0006,1414
  60.  
  61. then forwarding to sm0rgv will take place only during hours
  62. numbered 00, 01, 02, 03, 04, 05, 06 and 14. Ticks of the mbox
  63. timer outside of these times will not cause mail to be forwarded
  64. to sm0rgv. The default interval for forwarding is 0023.
  65.  
  66. Connection route
  67.  
  68. This is the method by which communication is to be established
  69. with the remote BBS. The first token on the line is the type of
  70. protocol to be used. This is one of ax25, netrom or tcp.
  71. Following this is whatever further information the chosen
  72. protocol requires to make the connection. An example connection
  73. route for a simple ax25 connection on interface ax0 is:
  74.  
  75. ax25 ax0 g3dlh
  76.  
  77. Connection commands
  78.  
  79. Connection commands may, optionally, follow the connection route.
  80. These take the form of a full stop (period), followed by the
  81. command which will be transmitted once the connection defined in
  82. the first line of the connection route is established.
  83.  
  84. For example, suppose that we wish to establish a netrom
  85. connection with sm0rgv-2, through the netrom node #sth67. Then
  86. the connection route and connection command portion of the record
  87. would look like:
  88.  
  89. netrom #sth67
  90.  .c sm0rgv-2     [ Please note that the full stop would be placed at
  91.                    the beginning of the line; I have placed it here
  92.                    indented by one column simply so that gateways
  93.                    which handle this message do not complain at
  94.                    having a line beginning with a full stop; this
  95.                    convention is followed throughout this documentation]
  96.  
  97. If the station is reached through digipeating, then the
  98. digipeater callsigns should be in the ax25 route to the
  99. destination callsign. That is, if you wish to forward traffic to
  100. w0ljf, using k2na as a digipeater, then you should have the line:
  101.  
  102. ax25 route add w0ljf k2na
  103.  
  104. in your autoexec file.
  105.  
  106. List of areas to be forwarded
  107.  
  108. This is a list, one per line, of entries in the /spool/mail
  109. directory which will be forwarded to the remote BBS. An entry of
  110. the form:
  111.  
  112. callsign
  113.  
  114. will cause the file /spool/mail/callsign.txt to be scanned for
  115. unread messages. Any such messages are sent to the remote BBS and
  116. deleted from the file.
  117.  
  118. One can also forward user areas using this mechanism. To do this,
  119. simply place a line containing the name of the area in the
  120. record. So, to forward amsat bulletins to the BBS, one would have
  121. a line:
  122.  
  123. amsat
  124.  
  125. This will search the /spool/mail/amsat.txt file; any messages
  126. contained therein which have not been forwarded to the BBS in
  127. question will be forwarded. They will NOT be deleted. The
  128. determining factor as to whether or not entries are deleted is
  129. that if the filename is present in the /spool/areas file, then
  130. there is NO deletion, otherwise there is.
  131.  
  132. Please note that ONLY FILES IN /spool/mail are checked. In
  133. particular, the outbound SMTP mail queue is NOT checked.
  134.  
  135. Changing the recipient address
  136.  
  137. Normally, NOS uses the information in the To: header line to
  138. determine the parameters used by the "S" command during BBS
  139. forwarding. As the To: header is unchanged by all /alias and
  140. /spool/rewrite machinations, the mail will be sent to the BBS
  141. addressed precisely as the originator of the message typed it.
  142. Occasionally, one might want to change this behaviour. In this
  143. case, a line of the form:
  144.  
  145. area  new_address
  146.  
  147. in the list of areas to be forwarded will replace the originally
  148. typed destination with the string new_address instead.
  149.  
  150. /alias
  151.  
  152. The alias file is used to map LOCAL names to other names, which
  153. may be either local or remote; additionally, from a single input
  154. message, the alias file permits one to produce multiple output
  155. messages. Thus, typical uses for the /alias file are: converting
  156. one local name to another, converting a local name to a remote
  157. name, and exploding a mail message so that it is passed on to
  158. several recipients.
  159.  
  160. The format of a record in the alias file is very simple:
  161.  
  162. aliasname       recipient1 recipient2 recipient3
  163. <tab> or <SP>   recipient4 ... recipientN
  164.  
  165. There is no separation between records in the /alias file other
  166. than a newline.
  167.  
  168. The aliasname is a local username; that is, it does not contain
  169. an "@" symbol. When the alias file is processed, if the
  170. destination of the message matches precisely the aliasname, then
  171. the mail is redirected to ALL of the alieased recipients.
  172.  
  173. Scanning of the /alias file is performed by the SMTP server. The
  174. SMTP timer (which controls the SMTP client) is kicked whenever
  175. the mailbox or SMTP server queues something for delivery by SMTP.
  176. Mail transport within a single NOS system is performed through
  177. the SMTP client/server mechanism. The result of these facts is
  178. that as soon as a piece of mail is entered to the mailbox, the
  179. SMTP client is kicked and attempts to deliver the mail (which has
  180. already been scanned by the rewrite mechanism - see below). If
  181. the mail is local to the NOS system (i.e. no "@" sign in the
  182. address), then the /alias file will be scanned and the name
  183. mappings take place.
  184.  
  185. A few lines in the /alias file might look something like:
  186.  
  187. bdale   bdale@n3eua
  188. local   fred@k0yum bdale@n3eua bill@ai0c.co.usa.na
  189.         n5op@n5op jim@k0jtz n0esg@n0esg
  190. g4bki   g4bki@gb7bil._2712.gbr.eu
  191.  
  192. The system must know how to deliver traffic to each of the
  193. individual addresses in the style in which they are entered in
  194. the /alias file. If the system does not know how to deliver one
  195. of the new addresses, then it will send it to the SMTP gateway
  196. station defined by the 'smtp gateway' command.
  197.  
  198. Note that it is reasonable, and sometimes desireable, to have
  199. alias records of the form:
  200.  
  201. area    area dest1 dest2 ...
  202.  
  203. As the /alias file is scanned only once (see below), this does
  204. not result in an infinite recursion.
  205.  
  206. /spool/rewrite
  207.  
  208. The rewrite file is used to perform a one-to-one mapping between
  209. destination addresses as received by NOS and destination
  210. addresses as actually used by NOS. Each record within the rewrite
  211. file comprises a single line, containing either two or three
  212. entries separated by spaces. The first field is the template
  213. field; if a destination address matches the template, it is
  214. replaced by the second field. The third field, which is optional,
  215. is the single letter "r", which, if present, tells NOS to rescan
  216. the rewrite file, using the new destination address to attempt to
  217. match against the templates.
  218.  
  219. A template may contain asterisks. These stand for a match of any
  220. number of characters (including zero). In the second field, the
  221. character "$", followed by a single digit in the range 1 to 9,
  222. represents the string that matched the respective asterisk in the
  223. template. By way of example, suppose that there is a line in the
  224. rewrite file which looks like:
  225.  
  226. *@* $1%$2@g1emm.ampr.org
  227.  
  228. Then, any traffic reaching the system through the mailbox or the
  229. SMTP server, but which is supposed to go to a remote system, will
  230. be redirected to go through g1emm.ampr.org. Suppose that a user
  231. logs on, and sends a message to n0gbe@nq0i. Then the rewrite file
  232. attempts to match "n0gbe@nq0i" against the entry *@*. It matches,
  233. and assignes $1 the value n0gbe, and $2 the value nq0i. The mail
  234. file as written to the disk will no longer be to n0gbe@nq0i, but,
  235. rather, to n0gbe%nq0i@g1emm.ampr.org. [The nomenclature
  236. station1%station2@station3 means the final destination is
  237. station1@station2, and this traffic is to be routed through the
  238. gateway station3.]
  239.  
  240. As soon as a template match is found, the conversion is performed
  241. and scanning is stopped, unless the third "r" field is present,
  242. in which case scanning restarts from the top of the file.
  243.  
  244. N.B. It is a good idea to have a line of the form:
  245.  
  246. *@*.ampr.org $1@$2.ampr.org
  247.  
  248. at the beginning of your rewrite file. This will cause all
  249. amprnet traffic to be caught early in the rewrite scan, and no
  250. further scanning (and, hence, no unexpected substitutions) will
  251. take place.
  252.  
  253. Scanning procedure
  254.  
  255. The two files which are used to determine the disposition of
  256. traffic are scanned under slightly different circumstances. Note
  257. that neither the /alias nor the /spool/rewrite scan makes any
  258. actual changes to the contents of the traffic. In particular, the
  259. To: field remains exactly as it was first entered into the
  260. system.
  261.  
  262. There are four possible entry routes for traffic into the system:
  263. SMTP, through the mailbox by a user, through the mailbox by a
  264. BBS, and via an external program (like BM) or creation of the
  265. files manually. NOS determines if a piece of traffic was entered
  266. into the system by a BBS by looking for a BBS system ID (like the
  267. "[NET-H$]" block issued by NOS) on the incoming connection prior
  268. to messages being uploaded.
  269.  
  270. Traffic received by SMTP server
  271.  
  272. 1. The rewrite file is scanned and any changes applied (unless
  273. the traffic was recieved through the local mailbox; in that case,
  274. this step does not occur);
  275. 2. If the traffic appears to be local then the alias file is
  276. scanned and any changes or explosions applied.
  277. 3. Any copies local to the system are delivered; copies for
  278. remote delivery are placed in the SMTP queue.
  279.  
  280. Traffic received by mailbox from user
  281.  
  282. 1. The rewrite file is scanned and any changes applied;
  283. 2. The traffic is passed to the SMTP client.
  284.  
  285. Traffic received by mailbox from BBS
  286.  
  287. 1. The rewrite file is scanned and any changes applied;
  288. 2. The traffic is passed to the SMTP client.
  289.  
  290. Traffic entered by external mechanism
  291.  
  292. 1. No scanning occurs;
  293.  
  294. 2. The traffic is passed to the SMTP client.
  295.  
  296. Headers
  297.  
  298. Appropriate RFC-822 headers are added to all incoming traffic.
  299. Traffic entering through the mailbox recieves a full complement
  300. of RFC-822 headers; traffic coming through the SMTP server has
  301. only a "Received:" header applied. On forwarding to a BBS, if an
  302. item of traffic contains BBS R: headers, the RFC-822 header is
  303. converted to an appropriate R: line at the time that NOS forwards
  304. the message. (This change only occurs for BBS forwarding;
  305. forwarding by SMTP retains the RFC-822 headers.)
  306.  
  307. Bulletin Identifiers (BIDs)
  308.  
  309. The AX.25 BBS system has evolved a reasonably efficient way of
  310. reducing overhead when forwarding bulletins. When a bulletin is
  311. originated on a BBS, it is given a unique bulletin identifier
  312. (BID). This BID should (theoretically) travel with the bulletin,
  313. and should never be changed during the distribution of the
  314. bulletin. Each system keeps track of all received BIDs. If a
  315. forwarding station wishes to forward a bulletin to a BBS, then
  316. the receiving station checks its local list of known BIDs and
  317. informs the transmitting station if it already posesses the
  318. bulletin in question. The NOS mailbox conforms to this protocol.
  319. Received BIDs are stored in the file /spool/history, and are
  320. encoded in the Message-ID: header line of the message by NOS.
  321. Messages forwarded from areas listed in the /areas file will have
  322. their BID (re)generated from the Message-ID: line. Note that ALL
  323. messages from public areas are forwarded with a BID, whether or
  324. not the message was produced with the "SB" command. Like other
  325. BBSes, NOS will inform a transmitting station not to transmit a
  326. bulletin if it is one that NOS already has locally; likewise, it
  327. understands similar messages from other stations to which it
  328. tries to forward.
  329.  
  330. Note that the BID mechanism is not a part of the SMTP world. If
  331. you are forwarding bulletins through SMTP, there is no mechanism
  332. by which the receiving station can reject the attempted delivery
  333. of a bulletin, even if it already exists on the recipient system.
  334. (Note that a possible workaround is to deliver bulletins to
  335. TCP/IP stations using TCP instead of SMTP. Alternatively, one
  336. could use NNTP, as NNTP commands utilise the Message-ID: line,
  337. from which the BID is derived.) The BID is preserved no matter
  338. which mechanism is used to deliver the bulletin.
  339.  
  340. Traffic in practice
  341.  
  342. Now, the big question is, how does one set up these various files
  343. to perform intelligent manipulation of mail? A number of examples
  344. follow. Note that, often, there is more than one way to
  345. accomplish an objective. The following are merely examples (and
  346. not necessarily the most efficient method possible for any given
  347. case). The format used will be:
  348.  
  349. typed destination -> intended destination
  350.  
  351. followed by the necessary entries in the alias (/alias), rewrite
  352. (/spool/rewrite) and forwarding (/spool/forward.bbs) files.
  353.  
  354. Using familiar names - SMTP destination
  355.  
  356. bdale -> bdale@n3eua.ampr.org
  357.  
  358. alias:
  359. bdale   bdale@n3eua.ampr.org
  360.  
  361. rewrite:
  362. forward:
  363.  
  364. Exploding local mail
  365.  
  366. sysops -> nq0i, n5op@n5op.ampr.org
  367.  
  368. alias:
  369. sysops  nq0i n5op@n5op@ampr.org
  370.  
  371. rewrite:
  372. forward:
  373.  
  374. Using familiar names - BBS forwarding
  375.  
  376. g4bki -> g4bki@gb7bil._2712.gbr.eu, to be forwarded by ai0c
  377.  
  378. alias:
  379. rewrite:
  380. forward:
  381. ai0c
  382. ax25 ax1 ai0c
  383. g4bki g4bki@gb7bil._2712.gbr.eu
  384. ai0c
  385.  
  386. Handling incoming bulletins by subject
  387.  
  388. tcpip@* -> nq0i, tcpip, bdale@n3eua.ampr.org, ai0c@ai0c [a BBS]
  389.  
  390. alias:
  391. tcpip   nq0i tcpip bdale@n3eua.ampr.org ai0c
  392.  
  393. rewrite:
  394. tcpip@* tcpip
  395.  
  396. forward:
  397. ai0c
  398. ax25 ai0c
  399. ai0c
  400.  
  401. Let's walk through the above example. An incoming item comes in
  402. addressed to TCPIP@ALLUS. A scan is made through the rewrite
  403. file, and a match is found. The item is redirected to tcpip. The
  404. alias file is scanned; a total of four copies of the item exist
  405. after this, three in local areas tcpip, nq0i and ai0c, and one on
  406. the SMTP queue (for bdale@n3eua.ampr.org). When the mailbox timer
  407. next ticks, the mail in the local ai0c area will be forwarded on
  408. the ax1 interface to ai0c.
  409.  
  410. Routing based on Hierarchical addressing
  411.  
  412. Wyoming -> KE7VS (SMTP)
  413. Nebraska -> AG0N (BBS over the NETROM, NETROM ID WNBBS)
  414. Europe -> W0LJF (BBS over AX.25)
  415.  
  416. alias:
  417. rewrite:
  418. *.noam            $1.na r
  419. *.us              $1.usa.na r
  420. *.usa             $1.usa.na r
  421.  
  422. *.ne              $1.ne.usa.na r
  423. *.wy              $1.wy.usa.na r
  424.  
  425. *@*.*.wy.usa.na   $1%$2.$3.wy.usa.na@ke7vs
  426. *@*.wy.usa.na     $1%$2.wy.usa.na@ke7vs
  427.  
  428. *.ne.usa.na     ag0n
  429.  
  430. *.eu            w0ljf
  431.  
  432. forward:
  433. ag0n
  434. netrom ax0 wnbbs
  435. ag0n
  436. ----------
  437. w0ljf
  438. ax25 ax1 w0ljf
  439. w0ljf
  440. ----------
  441.  
  442. Why is the example rewrite file apparently so complicated? This
  443. is to handle poorly constructed hierarchical addresses in a
  444. reasonable way. A full U.S. hierarchical address has the form:
  445. callsign@BBS.#localid.state.usa.na. Many states have no #localid
  446. field. In the example rewrite file above, the first three lines
  447. convert non-standard, but frequently used, U.S. designators to
  448. the more standard format. It is common for users not to use a
  449. full hierarchical address if the destination is relatively local.
  450. For eample, a user might easily use only .wy instead of the full
  451. .wy.usa.na if he is geographically close to Wyoming. The second
  452. grouping of two lines handles this problem. Note the third, "r",
  453. field in all the entries so far.
  454.  
  455. The remainder of the file handles properly formatted hierarchical
  456. addresses. The two Wyoming entries handle the cases with and
  457. without a #localid field. Differentiation between these cases is
  458. not necessary for BBS forwarding.
  459.  
  460. General bulletin handling
  461.  
  462. The details of bulletin handling will vary somewhat from place to
  463. place, as there are several distinct styles of bulletin handling
  464. currently in use in the AX.25 BBS world. In general, it is
  465. necessary to arrange one's system so that it accepts bulletins
  466. from BBSes, forwards them to one or more stations, and also
  467. handles intelligently bulletins input by users into NOS.
  468.  
  469. Suppose that we sish to handle bulletins @JUNK. We are to deposit
  470. them locally in the junk area, and also forward to BBS g4bki. We
  471. also know that we generally receive @JUNK bulletins from g4amj, a
  472. local BBS which handles much bulletin traffic.
  473.  
  474.  
  475. alias:
  476. rewrite:
  477. *@junk   junk
  478.  
  479. forward:
  480. g4bki
  481. ax25 ax1 g4bki
  482. g4bki
  483. junk
  484. ----------
  485. g4amj
  486. ax25 ax1 g4amj
  487. g4amj
  488. junk
  489. ----------
  490.  
  491. All incoming @JUNK traffic is written to the junk area (which
  492. should be an explicit entry in the /spool/areas file). Each tick
  493. of the mailbox timer, NOS scans the junk area for traffic not
  494. forwarded to g4bki or g4amj and attempts to deliver unforwarded
  495. bulletins. Usually, g4amj will respond with a "Have it" message
  496. and the bulletin will not be forwarded. Any bulletins @JUNK
  497. deposited locally by users will automatically be sent to both
  498. g4bki and g4amj.
  499.  
  500. Questions and Answers
  501.  
  502. Q. Under what circumstances does NOS request reverse forwarding
  503. from a BBS?
  504.  
  505. A. NOS requests a reverse forward after completing any forwards
  506. of its own to the BBS. If no traffic was queued for a given BBS,
  507. then no connection is attempted, so no reverse forward request is
  508. issued.
  509.  
  510.  
  511. Q. What kinds of message types does the NOS mbox support?
  512.  
  513. A. Basically, NOS supports all two letter commands starting with
  514. an "S". If the mailbox has not received an SID banner (the
  515. "[NET-H$]") from a connected station, then an SF command will
  516. send a followup to the address specified on the command line. The
  517. SR command will send a reply to the current message. One can also
  518. issue the command "SR <number>", where <number> is the number of
  519. the message to which you want to generate a reply. All other
  520. variations cause an X-BBS-Msg-Type: header to be added to the
  521. message. When a message with such a line is forwarded to a BBS,
  522. it is sent to the BBS with the appropriate message type as the
  523. second letter in the "S" command to the BBS.
  524.  
  525. If NOS has received a valid SID, then ALL S commands are handled
  526. by the X-BBS-Msg-Type: mechanism outlined above.
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567.  
  568.  
  569.  
  570.  
  571.  
  572.  
  573.  
  574.  
  575.  
  576.  
  577.  
  578.  
  579.  
  580.  
  581.  
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595. Logic map of the mailbox
  596.  
  597. ============== AX.25 === NET/ROM === Ethernet === Loopback =================
  598.        |                   |                   |                   |
  599.        |                   |                   |                   |
  600. +--------------+    +--------------+    +--------------+    +--------------+
  601. |              |    |              |    |              |    |              |
  602. |   Mailbox    |    | SMTP client  |    | SMTP server  |    | BBS Forward  |
  603. |              |    |              |    |              |    |              |
  604. +--------------+    +--------------+    +--------------+    +--------------+
  605.        |                   ^                   |                   ^
  606.        |                   |                   |                   |
  607.        v                   |                   v                   |
  608. +--------------+    +--------------+    +--------------+    +--------------+
  609. |              |    |              |    |              |    |              |
  610. | Add RFC822   |    | Use MX or A  |    | Add Received |    | Add own R:   |
  611. | header suite |    | type records |    | line         |  +>| line         |
  612. |              |    |              |    |              |  | |              |
  613. +--------------+    +--------------+    +--------------+  | +--------------+
  614.        |                   ^                   |          |        ^
  615.        |                   |                   |          |        |
  616.        v                   |                   v          |        |
  617. +--------------+    +--------------+    +--------------+  | +--------------+
  618. |              |    |              |    |              |  | |              |
  619. | Get Rewrite  |    | Use optional |    | Apply Rewrite|  | | Strip RFC822 |
  620. | file address |    | SMTP gateway |    | file address |  | | header suite |
  621. |              |    |              |    |              |  | |              |
  622. +--------------+    +--------------+    +--------------+  | +--------------+
  623.        |                   ^                   |          |        ^
  624.        |                   |                   |          |        | Yes
  625.        v                   |                   v          |        |
  626. +--------------+           |            +--------------+  | +--------------+
  627. |              |   No      |            |              |  | |              |
  628. | Local addr?  |-------+   |            | Alias file   |  +-| Any R: lines?|
  629. |              |       |   |            |              | No |              |
  630. +--------------+       |   |            +--------------+    +--------------+
  631.        |               |   |                |  |  |                ^
  632.        | Yes           |   |                |  |  |                |
  633.        v               |   |                v  v  v                |
  634. +--------------+       v   |            +--------------+    +--------------+
  635. |              |    +--------------+    |              |    |              |
  636. | Apply Rewrite|    |              | No | Local        |Yes | /spool/mail/ |
  637. | file address |--->| SMTP queue   |<---| address?     |--->| directory    |
  638. |              |    |              |    |              |    |              |
  639. +--------------+    +--------------+    +--------------+    +--------------+
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.